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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The IETF Trust (2006). 
Abstract 


When experimenting with or extending protocols, it is often necessary 
to use some sort of protocol number or constant in order to actually 
test or experiment with the new function, even when testing in a 
closed environment. This document reserves some ranges of numbers 
for experimentation purposes in specific protocols where the need to 
support experimentation has been identified, and it describes the 
numbers that have already been reserved by other documents. 
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Introduction 


[RFC3692] recommends assigning option numbers for experiments and 
testing. This document documents several such assignments for the 
number spaces whose IANA considerations are documented in [RFC2780]. 
This document generally follows the form of [RFC2780]. 


When using these values, carefully consider the advice in Sections 1 
and 1.1 of [RFC3692]. It is not appropriate to simply select one of 
these values and hard code it into a system. 


Note: while [RFC3692] says that it may not be necessary to allocate 
values for UDP and TCP ports, Sections 6 and 7.1 explicitly reserve 
ports for this purpose to avoid any possible conflict. 


Fields in the IPv4 Header 
The IPv4 header [RFC0791] contains the following fields that carry 


values assigned by the IANA: Version, Type of Service, Protocol, 
Source Address, Destination Address, and Option Type. 


Se IP Version Field in the IPv4 Header 


The Version field in IPv4 packets is always 4. 


.2. IPv4 Type of Service Field 


[RFC2474] defines Pool 2 (all code points xxxxll, where ’x’ refers to 
either ’0’ or '1’) as Experimental/Local Use, so no additional code 
points should be needed. The Explicit Congestion Notification (ECN) 
field [RFC3168] has no free code points to assign. 


.3. %IPv4 Protocol Field 


[RFC3692] allocates two experimental code points (253 and 254) for 
the IPv4 Protocol field. 


-4. IPv4 Source and Destination Addresses 


-4.1. IPv4 Unicast 


No experimental IPv4 addresses are defined. For certain experiments, 
the address ranges set aside for Private Internets in [RFC1918] may 
be useful. It is not appropriate to use other special-purpose IPv4 
addresses [RFC3330] for experimentation. 
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At the time of this writing, some Internet Registries have policies 
allowing experimental assignments from number spaces that they 
control. Depending on the experiment, the registry, and their 
policy, this may be an appropriate path to pursue. 


2.4.2. IPv4 Multicast 


The globally routable group 224.0.1.20 is set aside for 
experimentation. For certain experiments, the administratively 
scoped multicast groups defined in [RFC2365] may be useful. This 
document assigns a single link-local scoped group, 224.0.0.254, anda 
single scope-relative group, 254. 


2.5. IPv4 Option Type Field 


This document assigns a single option number, with all defined values 
of the "copy" and "class" fields, resulting in four distinct option 
type codes. See Section 8 for the assigned values. 


3. Fields in the IPv6 Header 


The IPv6é header [RFC2460] contains the following fields that carry 
values assigned from IANA-managed name spaces: Version, Traffic 
Class, Next Header, Source and Destination Address. In addition, the 
IPv6 Hop-by-Hop Options and Destination Options extension headers 
include an Option Type field with values assigned from an IANA- 
managed name space. The IPv6 Routing Header contains a Type field 
for which there is not currently an explicit IANA assignment policy. 


Bede. IP Version Field in the IPv6 Header 
The Version field in IPv6 packets is always 6. 

3.2. IPv6 Traffic Class Field 
[RFC2474] defines Pool 2 (all code points xxxxll, where ’x’ refers to 
either ’0’ or '1’) as Experimental/Local Use, so no additional code 
points should be needed. The ECN field [RFC3168] has no free code 
points to assign. 


3.3. IPv6 Next Header Field 


[RFC3692] allocates two experimental code points (253 and 254) for 
the IPv6 Next Header field. 
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IPv6 Source and Destination Addresses 
1. IPv6 Unicast Addresses 


[RFC2928] defines a set of IPv6 addresses for testing and 
experimental usage: 


The block of Sub-TLA IDs assigned to the IANA (i.e., 
2001:0000::/29 — 2001:01F8::/29) is for assignment for testing and 
experimental usage to support activities such as the 6bone, and 
for new approaches like exchanges. 


However, at this writing, there are no RFC3692-style experimental 
IPv6 addresses assigned. [HUSTON0O5] creates an IANA registry that 
may in the future contain such assignments. For certain experiments, 
Unique Local Addresses [RFC4193] may be useful. It is not 
appropriate to use addresses in the documentation prefix [RFC3849] 
for experimentation. 


At the time of this writing, some Internet Registries have policies 
allowing experimental assignments from number spaces that they 
control. Depending on the experiment, the registry, and their 
policy, this may be an appropriate path to pursue. 


-2. IPv6 Multicast Addresses 


The group FFOX::114 is set aside for experimentation at all scope 
levels. Smaller scopes may be particularly useful for 
experimentation, since they are defined not to leak out of a given 
defined boundary, which can be set to be the boundary of the 
experiment. For certain experiments, other multicast addresses with 
the T (non-permanently-assigned or "transient" address) bit [RFC4291] 
set may be useful. 


IPv6 Hop-by-Hop and Destination Option Fields 

This document assigns a single option type, with all possible values 
of the "act" and "chg" fields, resulting in eight distinct option 
type codes. See Section 8 for the assigned values. 


IPv6 Routing Header Routing Type 


This document assigns two values for the Routing Type field in the 
IPv6 Routing Header, 253 and 254. 
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4. Fields in the IPv4 ICMP Header 
This document assigns two ICMPv4 type numbers, 253 and 254. ICMPv4 
code values are allocated per type, so it’s not feasible to assign 
experimental values in this document. 

5. Fields in the IPv6é ICMP Header 
[RFC4443] includes experimental ICMPv6 type values for Informational 
(200, 201) and Error (100, 101) message types. ICMPv6 code values 
are allocated per type, so it’s not feasible to assign experimental 
values in this document. 

5.1. IPv6é Neighbor Discovery Fields 
The IPv6 Neighbor Discovery header [RFC2461] contains the following 
fields that carry values assigned from IANA-managed name spaces: 
Type, Code, and Option Type. 

5.1.1. IPv6é Neighbor Discovery Type 


The Neighbor Discovery Type field is the same as the ICMPv6é Type 
field. See Section 5 for those code points. 


5.1.2. IPv6 Neighbor Discovery Code 


The ICMPv6 Code field is not used in IPv6 Neighbor Discovery, so no 
experimental code points are necessary. 


5.1.3. IPv6é Neighbor Discovery Option Type 


This document assigns two IPv6 Neighbor Discovery Option Types, 253 
and 254. 


6. Fields in the UDP Header 


Two system ports, 1021 and 1022, have been reserved for 
experimentation for UDP and TCP. 
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7. Fields in the TCP Header 
7.1. TCP Source and Destination Port Fields 


Two system ports, 1021 and 1022, have been reserved for 
experimentation for UDP and TCP. 


7.2. Reserved Bits in TCP Header 


There are not enough reserved bits to allocate any for 
experimentation. 


7.3. TCP Option Kind Field 


Two TCP options, 253 and 254, have been reserved for experimentation 
with TCP Options. 


8. IANA Considerations 
The new assignments are summarized below. 
IPv4 Multicast Addresses (multicast-addresses (224.0.0/24) Local 
Network Control Block section) (Section 2.4.2) 
Group Address Name 


224.0.0.254 RFC3692-style Experiment (*) 
IPv4 Multicast Addresses (multicast-addresses relative addresses 
section) (Section 2.4.2) 


Relative Description 


IPv4 Option Numbers (ip-parameters initial section) (Section 2.5) 


Copy Class Number Value 


0 0 30 30 
0 2 30 94 
1 0 30 158 
1 2 30 222 
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IPv6 Option Types (ipv6-parameters Section 5.b.) (Section 3.5) 
HEX act chg rest 
Oxle 00 0 11110 
Ox3e 00 1 LLL10 
Ox5e 01 0 11110 
Ox7e 01 1 11110 
Ox9e 10 0 11110 
Oxbe 10 1 11110 
Oxde 11 0 11110 
Oxfe 11 1 11110 


IPv6 Neighbor Discovery Option Formats (icmpv6-parameters) 
(Section 5.1.3) 


Type Description 


253 RFC3692-style Experiment 1 (*) 
254 RFC3692-style Experiment 2 (*) 


IPv6 Routing Header Routing Types (ipv6-parameters Section 5.c.) 
(Section 3.6) 


Type Description 


253 RFC3692-style Experiment 1 (*) 
254 RFC3692-style Experiment 2 (*) 


ICMPv4 Type Numbers (icmp-parameters) (Section 4) 
Type Name 


253 RFC3692-style Experiment 1 (*) 
254 RFC3692-style Experiment 2 (*) 
System Port Numbers (port-numbers) (Sections 6 and 7.1) 


Keyword Decimal Description 


expl 1021/udp RFC3692-style Experiment 1 (*) 
expl 1021/tcp RFC3692-style Experiment 1 (*) 
exp2 1022/udp RFC3692-style Experiment 2 (*) 
exp2 1022/tcp RFC3692-style Experiment 2 (*) 
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TCP Option Numbers (tcp-parameters) (Section 7.3) 


Kind Length Meaning 


253 N RFC3692-style Experiment 1 (*) 
254 N RFC3692-style Experiment 2 (*) 


Each of these registrations is accompanied by the following footnote: 


(*) It is only appropriate to use these values in explicitly- 
configured experiments; they MUST NOT be shipped as defaults in 
implementations. See RFC 3692 for details. 


9. Security Considerations 


Production networks do not necessarily support the use of 
experimental code points in IP headers. The network scope of support 
for experimental values should carefully be evaluated before 
deploying any experiment across extended network domains, such as the 
public Internet. The potential to disrupt the stable operation of 
the network hosting the experiment through the use of unsupported 
experimental code points is a serious consideration when planning an 
experiment using such code points. 


Security analyzers such as firewalls and network intrusion detection 
monitors often rely on unambiguous interpretations of the fields 
described in this memo. As new values for the fields are assigned, 
existing security analyzers that do not understand the new values may 
fail, resulting in either loss of connectivity, if the analyzer 
declines to forward the unrecognized traffic, or in loss of security 
if it does forward the traffic and the new values are used as part of 
an attack. Assigning known values for experiments can allow such 
analyzers to take a known action for explicitly experimental traffic. 


Because the experimental IPv4 options defined in Section 2.5 are not 
included in the IPsec AH [RFC4302] calculations, it is not possible 
for one to authenticate their use. Experimenters ought to keep this 
in mind when designing their experiments. Users of the experimental 
IPv6 options defined in Section 3.5 can choose whether or not the 
option is included in the AH calculations by choosing the value of 
the "chg" field. 


When experimental code points are deployed within an administratively 
self-contained network domain, the network administrators should 
ensure that each code point is used consistently to avoid 
interference between experiments. When experimental code points are 
used in traffic that crosses multiple administrative domains, the 
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10. 


10. 


experimenters should assume that there is a risk that the same code 
points will be used simultaneously by other experiments and thus that 
there is a possibility that the experiments will interfere. 
Particular attention should be given to security threats that such 
interference might create. 
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